



Abschlussprfung Sommer 2026
Fachinformatiker fr Anwendungsentwicklung
Dokumentation der betrieblichen Projektarbeit

Thema
Optimierung der Auftragsverarbeitung im Warehouse Control Systems mittels Prozesssteuerung in C#

Prfling
Kai Krger
E-Mail: kai.oliver.k@web.de

Betreuer
Sebastian Badour
E-Mail: s.badour@gebhardt-group.com

Betrieb
Gebhardt Frdertechnik GmbH
Neulandstrae 28, 74889 Sinsheim

Inhaltsverzeichnis
Abbildungsverzeichnis	4
Tabellenverzeichnis	4
1.	Einleitung	5
1.1	Das Unternehmen	5
1.2	Projektziel	5
1.3	Projektabgrenzung	5
1.4	Projektumfeld & Schnittstellen	6
1.4.1	Administrative Schnittstelle (WMS/Host)	6
1.4.2	Ausfhrungsebene (SPS/PLC)	6
1.4.3	Datensynchronisation und Technologie-Stack	6
1.4.4	Test- und Simulationsumgebung	6
1.4.5	Relevante Prozesse	7
2.	Projektplanung	7
2.1	Projektphasen & Zeitplanung	7
2.1.1	Vorgehensmodell	7
2.1.2	Tabellarische Zeitplanung	8
2.2	Ressourcenplanung	8
2.2.1	Hardware	8
2.2.2	Software	8
2.2.3	Personal	8
2.3	Kostenplanung	9
3.	Analyse & Konzept	9
3.1	Ist-Analyse	9
3.2	Soll-Konzept	10
3.3	Wirtschaftlichkeitsbetrachtung	10
4.	Design & Architektur	10
4.1	Technische Entscheidungen	10
4.2	Systemarchitektur	11
5.	Realisierung	11
5.1	Implementierung	11
5.1.1	Datenmodell anpassen	11
5.1.2	Anpassung HostBooking Prozess	12
5.1.3	Anpassung ConveyorDispo Prozess	12
5.2	Qualittssicherung & Test	14
5.2.2	Testumgebung	14
5.2.3	Strukturierte Testszenarien	14
5.2.4	Aufgetretene Fehler	17
5.3	Abweichungen vom Soll-Konzept	18
6	Projektabschluss	18
6.1	Soll-Ist-Vergleich	18
6.1.2	Soll-Ist-Projektziele	18
6.1.3	Soll-Ist-Zeitplanung	19
6.2	Fazit & Ausblick	20
6.2.1 Persnliches und fachliches Fazit	20
6.2.2	Ausblick	20
Anhang	21
Kundendokumentation	21
Quellcode	21
Abnahmeprotokoll	21
Glossar	21
Prozess & Ablaufdiagramme	21
Quellenverzeichnis	21



Abbildungsverzeichnis

Abbildung 1 Taskboard	8
Abbildung 2 Ausschnitt Entity	13
Abbildung 3 Ausschnitt EF Core Entity Builder	13
Abbildung 4 IsDepartureReady Query	13
Abbildung 5 Flagging Restart Orders	14
Abbildung 6 Flagging Initial Orders	14
Abbildung 7 OrderListItem	14
Abbildung 8 departureFlaggedOrder Query	14
Abbildung 9 Scheduling	15
Abbildung 10 Pending Departure Orders Query	15
Abbildung 11 Order Restart	15
Abbildung 12 Pendingauftragsstart	15


Tabellenverzeichnis

Tabelle 1 Tabellarische Zeitplanung	8
Tabelle 2 Testmatrix	15
Tabelle 3 Soll-Ist-Projektziele	18
Tabelle 4 Soll-Ist-Zeitplanung	19

1. Einleitung

1.1 Das Unternehmen
Die Gebhardt Frdertechnik GmbH ist ein international agierendes Familienunternehmen mit Sitz in Sinsheim, das sich auf die Entwicklung und Herstellung modularer Intralogistiksysteme spezialisiert hat. Mit ber 70 Jahren Erfahrung bietet Gebhardt ein breites Spektrum an Lsungen  von der Frder- und Lagertechnik bis hin zu komplexen Warehouse Control Systemen (WCS). Ein zentraler Baustein des Portfolios ist die Softwareplattform GEBHARDT StoreWare, die Materialfluss- (MFS), Lagerverwaltungs- (LVS) und Visualisierungssysteme integriert, um eine effiziente Steuerung und Kontrolle der Warenstrme in automatisierten Lagern zu ermglichen.

1.2 Projektziel
Das Ziel des Projekts ist die Optimierung und Stabilisierung der Auftragsverarbeitung innerhalb des WCS. Aktuell fhrt die dezentrale Logik beim Starten von Transportauftrgen (OrdersHost) zu Race Conditions, da parallellaufende Prozesse die Mglichkeit haben, simultan denselben Auftrag zu starten. Dies resultiert bei ungnstigem Timing in inkonsistenten Datenbestnden und nicht abschliebaren Auftragsleichen innerhalb der Datenbank. Im Rahmen dieser Arbeit wird die Start-Logik im Prozess ConveyorDispo zentralisiert. Durch gezieltes Refactoring und die Implementierung thread-sicherer Mechanismen wird sichergestellt, dass Auftrge exklusiv verarbeitet werden, was die Fehleranflligkeit der Anlage signifikant reduziert, und die Stabilitt steigert.

1.3 Projektabgrenzung
Um den strengen Zeitrahmen von 80 Stunden zu wahren, wurde eine przise Abgrenzung des Leistungsumfangs vorgenommen, um eine unkontrollierte Ausweitung des Projektumfangs zu verhindern. 
Die eigene Entwicklungs- & Analyseleistung konzentriert sich auf folgende Schwerpunkte:
- Architekturanalyse & Konzeptentwurf: Detaillierte Codeanalyse der Prozesse HostBooking und ConveyorDispo zur Feststellung der zugrunde liegenden Race Condition. 
Identifizierung der relevanten Threads innerhalb der beiden Prozesse sowie der Codestellen.
Konzeptionierung einer zustandsorientierten, zentralen Prozesssteuerung im ConveyorDispo Prozess mittels Flag.

- Datenmodellierung: Anpassung des Datenmodells OrdersHost um das DepartureFlag innerhalb des Codes fr das Object-Relational-Mapping mit Entity Framework Core und der Datenbank selbst.

- Zentralisierung der Startlogik: Umbau des DepartureNotificationHandller Threads innerhalb von HostBooking. Entzug der Auftragsstartbefugnis hin zum flagbasierten Eventmelder. Des Weiteren werden die zyklischen Threads OrderManager und StartInitialOrdersHost zur Auswertung und zentralen Kapazittsprfung der Departureauftrge umgeschrieben.

- Integrationstest: Entwicklung und Durchfhrung von Praxisnahen Testszenarios innerhalb einer Emulation der Anlage. Dokumentation innerhalb einer strukturierten Testmatrix

Die folgenden angrenzenden Themengebiete wurden aus dem Projektrahmen ausgeschlossen:
- Altsystem-Logik fr Etra Boxen & PTL Sonderfunktionen: Behlter vom Typ EtraBox und manuelle Besttigungen an Pick-To-Light Pltzen verbleiben dezentral im HostBooking. Diese erfordern manuelle Sonderbehandlungen durch das Personal und wurden bewusst ausgegrenzt, um das Zeitfenster nicht zu berschreiten.

- Keine Modifikation der WMS-Schnittstelle:  Die Schnittstelle zum bergeordneten Host-Systems wird als gegeben und stabil betrachtet. Es werden keine Anpassungen auf WMS-Ebene vorgenommen.

1.4 Projektumfeld & Schnittstellen
Das Warehouse Control System (WCS) fungiert innerhalb der Logistikkette als entscheidende Middleware. Es bildet die Brcke zwischen der administrativen Ebene (WMS) und der physischen Ausfhrungsebene (SPS).

1.4.1 Administrative Schnittstelle (WMS/Host)
Die Anbindung an bergeordnete Lagerverwaltungssysteme (WMS) ist konfigurierbar und untersttzt zwei Kommunikationswege:
Datenbankgesttzter Datenaustausch: In Standard-Szenarien erfolgt der Austausch ber dedizierte Schnittstellentabellen:
Wcs.FromWms fr eingehende Nachrichten und Wcs.ToWms fr ausgehende Rckmeldungen. Die Kommunikation verluft asynchron: Ein WMS-Prozess schreibt Auftragsdaten in die Datenbank, die vom WCS-Prozess zyklisch gepollt und in interne initiale Transportauftrge (OrdersHost) transformiert werden.
Service-orientierte Architektur (REST-API): Fr die Anbindung externer WMS-Anbieter oder Cloud-Systeme stellt das WCS einen REST-Server bereit. Hierbei erfolgt der Datenaustausch via HTTP/JSON-Requests, was eine nahtlose Integration in moderne IT-Infrastrukturen ermglicht.

1.4.2 Ausfhrungsebene (SPS/PLC)
Die unterlagerte Kommunikation mit der Frdertechnik-Hardware erfolgt ber unverschlsselte TCP/IP-Telegramme in Echtzeit. Dieser Bereich ist fr die physische Sicherheit und den Durchsatz der Anlage kritisch:
Event-Handling: Sobald eine Ladeeinheit (LE) einen Arbeitsplatz verlassen will, sendet die SPS eine DepartureNotification. Dieses Telegramm enthlt unteranderem die Identifikationsnummer der LE sowie die aktuelle Position.
Handshake-Verfahren: Das WCS antwortet mit einem Departure Telegramm. Dieser Fahrbefehl ist die notwendige logische Freigabe fr die SPS, um die LE physisch vom Platz wegzubewegen. Ohne dieses Telegramm verbleibt das Transportgut im Stillstand.

1.4.3 Datensynchronisation und Technologie-Stack
Die prozessbergreifende Datenhaltung und Synchronisation innerhalb des WCS basiert auf einem Microsoft SQL Server. Der Datenzugriff wird ber das Entity Framework Core abstrahiert, um eine objektorientierte Verarbeitung der Materialflussdaten in C# zu ermglichen.

1.4.4 Test- und Simulationsumgebung
Zur Absicherung der Implementierung wird eine hochperformante Emulation der Frdertechnik innerhalb von Emulate3D eingesetzt. Diese umfasst die Frderanlage selbst, die Telegrammkommunikation zwischen WCS und der Frdertechnik mittels EMC Runner, die WCS-Prozesse und eine Testdatenbank. Diese fungiert als "Digitaler Zwilling" der physischen Anlage und ermglicht die Simulation von praxisnahen Szenarien.
1.4.5 Relevante Prozesse
Im Folgenden werden, die im Fokus der Arbeit stehenden Prozesse des WCS im Detail beschrieben, um die formalen Projektauflagen zu erfllen:
Der HostBooking Prozess: Dieser asynchrone Prozess verarbeitet alle eingehenden Nachrichten und Transportauftrge des bergeordneten WMS. Seine Hauptaufgaben sind das Einlesen der eingehenden Daten an der WMS-Schnittstelle (z.b. FromWMS Tabelle), das Anlegen initialer Transportauftrge in der Tabelle OrdersHost und die Pflege der LE-Stammdaten. Im IST-Zustand kann der Prozess in Spezialfllen Transportauftrge selbst starten und Freigabetelegramme an die SPS senden. Der Prozess greift auf die Datenbanktabellen FromWMS (welche vom Hostsystem befllt werden) und ToWMS (welche von HostBooking selbst befllt wird) zu. HostBooking ist ein Service, er luft permanent im Hintergrund und reagiert auf nderungen in der Datenbank oder auf eingehende Telegramme.
Der ConveyorDispo Prozess: Er ist das mathematische und logische Herzstck des Materialflussrechners. Seine primre Aufgabe ist die Disposition und Durchfhrung aller physischen Transporte auf der Frdertechnik. Er koordiniert das zeitliche und rumlich Schedulung mehrerer Transporte fr dieselbe LE, um Doppelstarts zu vermeiden. Er fhrt Ressourcen- & Kapazittschecks durch und erteilt die finalen Fahrbefehle. Der Prozess kommuniziert via TCP/IP Telegrammen mit der unterliegenden SPS und liest/schreibt Zustandsdaten in die MSSQL-Datenbank. Wie HostBooking ist er ebenfalls ein Hintergrunddienst und arbeitet in festen Intervallen.
2.  Projektplanung

2.1 Projektphasen & Zeitplanung
2.1.1 Vorgehensmodell
Fr die Durchfhrung des Projekts wird ein hybrides Vorgehensmodell gewhlt. Dieses kombiniert die Strukturierungsstrke des Wasserfallmodells mit der Flexibilitt agiler Methoden (Kanban-Tasktracking via Azure DevOps).
Aufgrund des festen Projektzeitraums ist eine Aufteilung der Arbeit auf sequenzielle Phasen fr eine terminliche Fertigstellung ideal. Jede Phase baut logisch auf den Ergebnissen der vorherigen auf. Um einer mglichen Ausweitung des Projektumfangs entgegenzuwirken, wird ein digitales Taskboard innerhalb von Azure DevOps verwendet (Siehe Abbildung 1). Dabei wurde das Projekt in 6 Phasen unterteilt: 

- Vorbereitung/Planung (Repository klonen, Emulation vorbereiten, Zugnge prfen),  
- Analyse (relevante Codestellen definiert, IST-Zustand untersucht, Fehlerquellen lokalisiert), 
- Konzeptionierung (SOLL-Logik entwerfen, UML-Modellierung), 
- Implementierung (Refactoring der C#-Klassen und DB-Anpassung) 
- Testung & Bugfixing (nderungen gegen realistische Szenarien im Emulator testen, ggf. Fehler beheben), 
- Dokumentation (Schriftliche Ausarbeitung der IHK-Arbeit)
Fr jede Phase werden Teilaufgaben in Form von Issues erstellt. Die nchste Phase wird erst nach Beendung aller Phasen-Issues begonnen. Dies verhindert unkontrollierte parallele Arbeitsschritte und sichert die Qualitt der Einzelergebnisse ab.

2.1.2 Tabellarische Zeitplanung
Die im Projektantrag grob geschtzte Phasen wurden zu Projektbeginn im Rahmen der Detailplanung przisiert und in die nachfolgenden Arbeitsphasen berfhrt, um eine przisere Zeitplanung zu ermglichen.
Tabelle 1 Tabellarische Zeitplanung
Phase
Geplante Stunden
Vorbereitung/Planung
8
Analyse
15
Konzeptionierung
15
Implementierung
10
Testung
12
Dokumentation
20
2.2 Ressourcenplanung
2.2.1 Hardware
Entwicklungs-Workstation: Entwicklungs-PC zur Softwareerstellung und Dokumentation.
SQL-Server: Server zum Hosten der MSSQL Test-Datenbank der Frderanlage.
Application-Server: Server zum Hosten der GEBHARDT StoreWare und WCS Dienste.
Emulations-VM: Ein dedizierter Server, auf dem der Digitale Zwilling der Frdertechnik luft, um die SPS-Kommunikation (TCP/IP-Telegramme) & den Materialfluss realittsgetreu zu simulieren.

2.2.2 Software
IDE: Microsoft Visual Studio 2022 als primre Entwicklungsumgebung.
Datenbank: Microsoft SQL Server 2019/2022 inklusive SQL Server Management Studio (SSMS) zur Datenanalyse und Schema-Anpassung.
Frameworks: .NET Framework / .NET Core unter Verwendung von Entity Framework Core als Object-Relational Mapper (ORM).
Versionsverwaltung: Git (Azure DevOps) zur Quellcode-Verwaltung und Dokumentation der Entwicklungsschritte.
Analyse-Tools: Visual Studio Debugger, Interner Telegramm-Logger zur Analyse der TCP/IP-Kommunikation zwischen WCS und Emulation, Wcs Test Tool.
Dokumentation: Microsoft Word zum Erstellen der Dokumentation und Creately zum Erstellen der UML- & Entity-Relationship-Diagramme. 

2.2.3 Personal
Prfling (Kai Krger): Verantwortlich fr die Analyse, Konzeption, Implementierung und Qualittssicherung des Projekts.
 Fachbetreuer (Sebastian Badour & Jesper Larrson): Ansprechpartner fr fachspezifische Rckfragen zur WCS-Architektur und Abnahme der Projektergebnisse.

2.3 Kostenplanung
Die Kostenplanung basiert auf dem Personalaufwand fr die Projektdauer von 80 Stunden. Da die bentigte Infrastruktur (Hardware, Software, Lizenzen) bereits im Unternehmen vorhanden ist, fallen keine zustzlichen Investitionskosten an.
Fr die Kalkulation wird ein Stundensatz von 65,00  angesetzt. Dieser setzt sich aus dem Brutto-Arbeitslohn, den Lohnnebenkosten sowie einem Gemeinkostenaufschlag fr den Arbeitsplatz und die IT-Infrastruktur zusammen.
Kostenberechnung:
- Gesamtkosten: 80 Stunden  65,00 /Stunde = 5.200,00 

3.  Analyse & Konzept
3.1 Ist-Analyse
Nach Analyse der Codebasis des WCS lsst sich der HostBooking Prozess als klarer Verursacher der Race Condition identifizieren. Bei einem DepartureNotification Telegramm der SPS ist der Prozess unter bestimmten Bedingungen in der Lage, initial angelegte Transportauftrge eigenmchtig zu starten. Ist eine LE gerade an einem Arbeitsplatz und wird abgemeldet (DepartureNotification wird gesendet), schaut HostBooking ob es fr diese LE noch Folgeauftrge an anderen Arbeitspltzen gibt. Ist dem der Fall, startet HostBooking eigenmchtig besagten Folgeauftrag. Dadurch entstehen folgende Probleme: 
Die Race Condition: Der ConveyorDispo Prozess pollt jede Sekunde nach initialen Transportauftrgen. Findet er einen, durchluft er Ressourcen- und Kapazittschecks fr den Transport, um sicherzustellen, dass durch den Start keine physischen Blockaden auf der Anlage entstehen. Wurden die Checks durchlaufen, startet ConveyorDispo den Transportauftrag und setzt den Status auf InProgress. Fllt diese LE jedoch nun unter den Spezialfall des HostBooking Prozesses, knnte er zeitgleich denselben Transportauftrag starten. Dadurch entsteht eine Transportauftragsleiche in der Datenbank, die nicht beendet werden kann. Es gibt jetzt zwei Transportauftrge fr eine physische LE auf der Anlage.
Fehlende Ressourcen- & Kapazittschecks: Durch das bergehen des ConveyorDispo Prozesses, der Auftragsstarts unter Gewhrleistung eines effizienten Materialflusses durch Ressourcen- & Kapazittschecks an Strecke und Ziel gewhrleistet, erhht man das Risiko von physischen Hindernissen auf der Frderanlage.
Des Weiteren gibt es einen architektonischen Konflikt, bei dem sich die Handlungsrume der Prozesse ConveyorDispo und HostBooking vermischen. Diese haben mit der funktionalen Integritt der Anlage in erster Linie allerdings nichts zu tun. HostBooking ist in der Theorie eine reine Kommunikationsschnittstelle zwischen dem WMS und der Anlage. Er soll Auftrge des Host-Systems verbuchen und Telegramme der Anlage entgegennehmen sowie verarbeiten. Aktuell kann er neben der bereits benannten Race Condition auch Auftrge neu starten. Kommt eine LE an einer Vorzone an und mchte sich jedoch in die Endzone bewegen, wird eine DepartureNotification an HostBooking gesendet. Hat der Transportauftrag der LE den Status InDestinationZone (die LE befindet sich in der Vorzone/kurz vor ihrem Ziel) wird sie von HostBooking auf InProgress gesetzt. ConveyorDispo ist jedoch in erster Linie die ausfhrende Gewalt und sollte demnach, auch wenn hier keine Ressourcenchecks ntig sind, den Transportauftrags(neu)start vornehmen.
Neben den nderungen in den Transportauftrgen werden auch die Handshake Telegramme (Departure Telegramm) dezentral als Antwort auf die DepartureNotification Telegramme vom HostBooking an die zustndige SPS gesendet. Diese werden bentigt, um die LE physisch auf der Anlage weiterfahren zu lassen.

3.2 Soll-Konzept
Die dezentrale Start-Logik soll einheitlich im ConveyorDispo Prozess zentralisiert werden, um eine klare Rollentrennung zu gewhrleisten und die zugrundeliegende Race Condition vermeiden.
Nur der ConveyorDispo Prozess darf nderungen am Status der Transportauftrge vornehmen und diese starten als auch das entsprechende Departure Telegramm versenden.
Der DeparturNotificationHandler von HostBooking wird zum reinen Eventmelder umgeschrieben. Er aktualisiert den physischen Ort der LE und signalisiert die entsprechende Departureanfrage durch eine Flag oder einen Status an den ConveyorDispo Prozess. Durch das Hinzufgen dieser oberflchlichen Flags, muss keine tiefliegende und verwurzelte Telegramm- oder WCS-Logik angepasst werden, was immense Zeitkosten sowie auch eine grere mgliche Fehleranflligkeit fr das gesamte System bedeuten wrde.

3.3 Wirtschaftlichkeitsbetrachtung
Da es sich bei der Fehlerbehebung um ein prventives Refactoring handelt, basiert die Kalkulation auf Erfahrungswerten und plausiblen Annahmen aus dem Support-Alltag von Gebhardt Frderanlagen. 
Im IST-Zustand sammeln sich durch die Race Condition Auftragsleichen in der Datenbank. Diese mssen manuell von einem Supportmitarbeiter ber das MSSQL Server Management Studio entfernt werden. Es muss sich per VPN aufgeschaltet und die Datenstze hndisch bereinigt werden.
Kostenaufwand: ca. 320  / Monat (basierend auf 2 Vorfllen/Woche mit jeweils einem Zeitaufwand von 30 Minuten und einem Kostensatz von 80/h)
Zudem verursacht das Starten von initialen Transportauftrgen durch den HostBooking ohne Ressourcen- & Kapazittschecks auf lange Sicht, gerade bei Hochlastphasen, Staus auf der Anlage was zu Performanceeinben fhrt und den Durchsatz verschlechtert.
Kostenaufwand: ca. 250  / Monat (basierend auf 1 Vorfall/Monat mit 15 Minuten Auswirkung, kalkuliert mit 1.000 /h Linien-Ausfallkosten)

Gesamtkalkulation (Break-Even-Point):
Einmalige Projektkosten (basierend auf der Kostenplanung): 5.200,00 
Monatliche Einsparung: 570 
Break-Even-Point: 5.200 / 570 = nach 9,12 Monaten
Amortisationszeit: ca. 9 Monate und 3 Tage

4.  Design & Architektur

4.1 Technische Entscheidungen
Wahl des Synchronisationsmechanismus: Anstatt den globalen Auftragsstatus TransportOrderStatus des OrdersHost Datenmodells fr die Prozessbergabe zu verwenden durch einen neuen Status wie ReadyForDispo, wird ein dediziertes Flag DepartureFlag eingefhrt.
Dies erlaubt eine atomare bergabe zwischen dem asynchronen Nachrichtenempfang HostBooking und der zyklischen Logikverarbeitung ConveyorDispo, ohne den fachlichen Status des Auftrags zu verlieren. Es ermglicht zudem die notwendige Fallunterscheidung zwischen Auftragsneustarts (vorrcken von Vorzone in Endzone, demnach keine Ressource- & Kapazittschecks ntig) und Folgeauftrag (voller Startprozess).

4.2 Systemarchitektur
Zentralisierung im ConveyorDispo: Der Thread StartInitialOrders wird der zentrale Verarbeitungspunkt fr initiale Transportauftrge, fr die ein Departure von HostBooking angefordert wurde, analog zu den initialen Transportauftrgen, die schon jetzt von diesem Thread bearbeitet werden. Zustzlich kmmert sich der OrderManager Thread des Prozesses um die Unterscheidung zwischen Auftragsneustarts (Status war Initial, ist nun durch StartInitialOrders Pending und das DepartureFlag ist auf true) welche das volle Programm an Ressourcen- & Kapazittschecks erhlt und Trackingauftrgen (Status ist InDestinationZone und DepartureFlag auf true) welche direkt gestartet werden.
ConveyorDispo sowie HostBooking haben Zugriff auf das neu implementierte DepartureFlag innerhalb des OrdersHost Datenmodells. Anstelle eines Auftragsstarts setzt HostBooking lediglich besagtes Flag auf true, um einen Departure Request zu signalisieren. ConveyorDispo pollt nach solchen Auftrgen und entscheidet ber den Start exklusiv.

5.  Realisierung

5.1 Implementierung
5.1.1 Datenmodell anpassen
Das Datenmodell von OrdersHost wurde um das Feld DepartureFlag erweitert (Nach Testung wurde ein weiteres Feld (DepartureLocation) hinzugefgt, siehe 5.3 Abweichung vom Projektplan)). In der bestehenden Datenbanktabelle OrdersHost wurden mittels Queries: 
ALTER TABLE Wcs.OrdersHost ADD DepartureFlag bit NULL;
ALTER TABLE Wcs.OrdersHost ADD DepartureLocation NVARCHAR(50) NULL;
die neuen Felder hinzugefgt. Des Weiteren wurden die Felder im OrdersHost Entity nachgezogen (Siehe Abbildung 2) und in den Entity Builder von Entity Framework Core aufgenommen (Siehe Abbildung 3). 
Abbildung 2 Ausschnitt Entity

Abbildung 3 Ausschnitt EF Core Entity Builder
Darber hinaus wurde eine Query fr die OrdersHost Entity geschrieben, um alle Eintrge zu erhalten, die bereit fr ein Departure sind (Siehe Abbildung 4).
Abbildung 4 IsDepartureReady Query
5.1.2 Anpassung HostBooking Prozess
Dem DepartureNotificationHandler Thread von HostBooking wurden die Mglichkeiten eines eigenmchtigen Transportauftragsstarts entzogen. Anstatt das HostBooking bei einem vorrcken in der Vorzone zum eigentlichen Ziel den Auftrag selbst neu startet (Status InDestinationZone auf InProgress) wird nun nur das DepartureFlag auf true und die DepartureLocation gesetzt (Siehe Abbildung 5). 
Abbildung 5 Flagging Restart Orders
Bei einem Folgeauftrag wird dieser bei einer DepartureNotification nicht mehr sofort von HostBooking gestartet, sondern nur das DepartureFlag gesetzt und die DepartureLocation festgehalten. Der Prozess ConveyorDispo holt sich anhand der neuen Departure Felder die Eintrge und startet sie nach eigenem Ermessen selbst (Siehe Abbildung 6). 
Abbildung 6 Flagging Initial Orders
5.1.3 Anpassung ConveyorDispo Prozess
Zur Datenhaltung der wichtigsten Felder innerhalb der OrdersHost Tabelle fr den Transportstart, wird der Record OrderListItem verwendet. Dieser wurde um die Felder DepartureFlag und DepartureLocation erweitert (Siehe Abbildung 7).

Abbildung 7 OrderListItem
Der StartInitialOrdersHost Thread von ConveyorDispo wurde um einen weiteren Check erweitert. Obwohl das Starten von Departureauftrgen hchste Prioritt hat, um Platz auf den Arbeitspltzen zu schaffen wird innerhalb des Codes klar darauf hingewiesen, dass abgebrochene Sequencerauftrge immer zuerst gestartet werden sollen. Analogisch dazu werden die Departureauftrge nach dem Sequencercheck als zweites abgerufen und verarbeitet. Die initialen Departureauftrge werden mittels IsDepartureReady Query aus der Datenbank gezogen und in ein OrderListItem um modelliert (Siehe Abbildung). 8). 
Abbildung 8 departureFlaggedOrder Query
Die OrderListItems werden anschlieend mit der Methode ScheduleOrdersHost des transportOrderService von Initial auf Pending gesetzt. Das Ereignis wird nach Durchfhrung geloggt (Siehe Abbildung 9). 
Abbildung 9 Scheduling
Der OrderManager Thread wurde um einen weiteren Durchgang erweitert fr die ausstehenden Departureauftrge im Status Pending und InDestinationZone. Mittels Query werden die Eintrge aus der Datenbank ausgelesen und verarbeitet (Siehe Abbildung 10).
Abbildung 10 Pending Departure Orders Query
Bei einem InDestinationZone Auftrag wurde lediglich die vorhandene Logik aus HostBooking ausgelagert. Der Status wird auf InProgress gesetzt, das Departure Telegramm gesendet und die Departure Felder zurckgesetzt (Siehe Abbildung 11).
Abbildung 11 Order Restart
Die ausstehenden Auftrge durchlaufen jedoch nun, wie alle anderen auch die Ressourcen- & Kapazittschecks, bevor sie vom ConveyorDispo mittels StartNextOrder Methode gestartet werden (Siehe Abbildung 12).
Abbildung 12 Pendingauftragsstart

5.2 	Qualittssicherung & Test
5.2.2 Testumgebung
Die Testumgebung wurde folgendermaen eingesetzt:
- Emulate3D: Visualisiert und berechnet das physikalische Verhalten der Frderanlage in Echtzeit
- EMC Runner: Ein Inhouse-Werkzeug zum Simulieren von Telegrammen auf TCP/IP Ebene zwischen SPS und WCS
- Gebhardt Prozess Manager: Ein Inhouse Programm in welchem die restlichen Prozesse des WCS und/oder des WMS zu testzwecken laufen und verwaltet werden (WMS Prozesse wurden beim Testen deaktiviert da das WCS Test Tool diese Rolle bernahm).
- Visual Studio: IDE in welcher die angepassten Prozesse ConveyorDispo & HostBooking zu testzwecken im Debugger laufen.
- WCS Test Tool: Ein Inhouse Werkzeug zum Simulieren des Host Systems. Mit diesem knnen Testszenarien durchgespielt werden, indem Befehle des WMS an das WCS simuliert werden. Zum Beispiel der Eingang eines Transportauftrags oder das Verbuchen einer LE in ein Lager.
- MSSQL Testdatenbank: Eine Kopie der Produktivdatenbank fr die Datenhaltung der Prozesse sowie zur berwachung der Anlage.

5.2.3 Strukturierte Testszenarien
Die Testmatrix basiert auf den offiziellen Abnahmekriterien der Fachabteilung und stellt sicher, dass alle geschftskritischen Betriebszustnde und potenziellen Fehlerquellen abgedeckt sind.




Tabelle 2 Testmatrix
Szenario
Ziel
Eingabe
SOLL Ergebnis
IST Ergebnis
Status
Normale Auslagerung
Nachweis fr korrekte Standard-Prozessabwicklung nach Refactoring.
LE befindet sich im Lager. Ein neuer initialer Transportauftrag wird fr diese angelegt mit Arbeitsplatz (PIC11) als Ziel.
ConveyorDispo identifiziert den neuen Initial-Auftrag ber StartInitialOrdersHost und setzt ihn auf Pending. OrderManager checkt, ob der Auftrag gestartet werden kann und startet ihn ggf. (Status InProgress). LE wird korrekt ausgelagert und zu PIC11 transportiert.
Durchfhrung erfolgreich. LE wurde aus Lager (AKL01) ausgelagert und zum angegebenen Arbeitsplatz (PIC11) transportiert.
BESTANDEN
Mehrfach-Auftrag
Nachweis der korrekten Zustandskoordination bei Folgeauftrgen whrend der Fahrt.
LE befindet sich auf dem Weg zum Arbeitsplatz (PIC11) Transportauftrag befindet sich InProgress. Whrenddessen kommt ein weiterer Transportauftrag im Status Initial fr diese LE rein.
Der Folgetransportauftrag verbleibt im Status Initial und wird erst gestartet, wenn ein Departure Telegramm vom Ziel des ersten Transportauftrags eingeht.
Durchfhrung erfolgreich. Folgetransportauftrag verbleibt im Status Initial.
BESTANDEN
Sofortiger Folgeauftrag
Nachweis der prozesssicheren bergabe via DepartureFlag zur Verhinderung von Race Conditions bei Platzabmeldung.
LE will vom Arbeitsplatz zurck in das Lager. Beim Senden der DepartureNotification wird ein neuer Transportauftrag fr diese LE gesendet.
Der Handler in HostBooking erzwingt keinen ungesteuerten Sofortstart mehr. Er setzt stattdessen das DepartureFlag auf true. ConveyorDispo liest das Flag im nchsten Arbeitszyklus aus, fhrt alle Ressourcen- & Kapazittsprfungen durch und startet den Transport kontrolliert.
Durchfhrung nicht erfolgreich. Beim Simulieren des Departures einer LE von einem Arbeitsplatz wird der Status des vorausgehenden Transportauftrags, welcher die LE an besagten Arbeitsplatz gebracht hat, nicht wie erwartet auf Finished gesetzt. Sie verbleibt im Status InDestinationZone. Daraus resultiert, dass dieser Transportauftrag in die Query fr die Neustarts innerhalb einer Vorzone fllt. Der vorausgehende Transportauftrag wird flschlicherweise wieder auf InProgress gesetzt. Des Weiteren wird der Folgeauftrag wie erwartet bearbeitet. HostBooking setzt die DepartureFlag sowie DepartureLocation zuverlssig & erfolgreich. Der Transportauftrag wird ebenfalls korrekt vom ConveyorDispo verarbeitet. Problem ist, man hat nun zwei Transportauftrge im Status InProgress. Stand jetzt ist unklar, ob es sich um einen Fehler im WCS Test Tool oder an der Implementierung der nderung handelt. Beim manuellen auf Finished setzen des vorausgehenden Transportauftrags ber die Datenbank ist die Durchfhrung des Testcases erfolgreich.
NICHT BESTANDEN
Leerbehlterwechsel
Nachweis der korrekten Daten- und Auftragsbereinigung am Arbeitsplatz.
LE wird am Arbeitsplatz leer. ber die FromWms-Schnittstelle wird eine HuChange Nachricht simuliert.
Das WCS verarbeitet die HuChange-Meldung, aktualisiert die LE-Stammdaten in der Datenbank, schliet den alten Transportauftrag ordnungsgem ab (Status = Finished) und bereitet den Transport des neuen Leerbehlters fehlerfrei vor.
Durchfhrung erfolgreich. Alter Auftrag wurde beendet, neuer Leerbehlterauftrag wurde korrekt initialisiert.
BESTANDEN
Sequencer-Einschleusung
Nachweis der gesteuerten Freigabe und Kapazittsprfung beim bergang von der Vorzone in den Sequenzer/Arbeitsplatz.
LE befindet sich in der Vorzone vor PIC10 im Status InDestinationZone. Ein Abmeldesignal (DepartureNotification) von der Vorzone wird ber das Testtool simuliert.
HostBooking schreibt das physische Ziel auf SEQ um und setzt DepartureFlag auf true. Der OrderManager im ConveyorDispo sucht nach Departureauftrgen.  Beim fund wird besagter Auftrag neu gestartet (Status von InDestinationZone auf InProgress. Darauffolgenden werden die Departure Felder innerhalb OrdersHost zurckgesetzt.
Durchfhrung erfolgreich. LE wurde kontrolliert unter der Nutzung des DepartureFlags und damit auch des OrderManager-Threads von ConveyorDispo in den Sequenzer berfhrt.
BESTANDEN

5.2.4 Aufgetretene Fehler
Das DepartureFlag war nicht korrekt zwischen Datenbank und Code synchronisiert. Was zu einem Nichtbestehen der Testcases Sofortiger Folgeauftrag & Sequencer Einschleusung fhrte. DepartureFlag war innerhalb des Codes (Entity Framework Kontext) als Nullable Boolean implementiert, whrend die Datenbank diese als not nullable bit abbildete. Diese Diskrepanz fhrte zu fehlerhaften If Abfragen innerhalb des Codes whrend der Runtime. Der Nullable Type wurde in der Datenbank nachgezogen da die Unterscheidung zwischen NULL und false innerhalb des Codes als unerheblich bewertet werden kann.
Des Weiteren verhielt sich das Positionsfeld der DepartureNotification anders als erwartet. Es hlt die Position des nchsten Ziels und nicht wie angenommen die des aktuellen Standorts der LE. Die Position der DepartureNotification wird bentigt, um das Departure Telegramm an die SPS zu senden. Da aktuell weder die OrdersHost noch LE Tabelle diese Information beinhaltet muss sich diese auf andere Weise fr den ConveyorDispo Prozess beschafft werden.
5.3 Abweichungen vom Soll-Konzept
Um ConveyorDispo zum Senden des Departure Telegramms die Position des vom HostBooking abgefangenen DepartureNotification Telegramms zugnglich zu machen, wurde sich dazu entschieden, neben dem DepartureFlag das OrdersHost Modell um ein weiteres Feld, DepartureLocation von Typ String, zu erweitern. Beim Eingehen des DepartureNotification Telegramms, setzt HostBookings DepartureNotificationHandler nun nicht mehr nur die Flag auf true, darber hinaus wird auch die Position innerhalb des DepartureNotification Telegramms gespeichert. Diese kann ConveyorDispo per Entity Framework Core abrufen. Mit dieser Zusatzinformation kann ConveyorDispo das Departure Telegramm an die SPS senden.

6 Projektabschluss

6.1 Soll-Ist-Vergleich
6.1.2 Soll-Ist-Projektziele
Tabelle 3 Soll-Ist-Projektziele
Projektziel (Soll)
Projektziel (Ist)
Status
Exklusiver Start von OrdersHost-Auftrgen ber den ConveyorDispo
Alle Starts und die dazugehrigen Departure Telegramme erfolgen exklusiv ber ConveyorDispo. HostBooking hat keine Startbefugnis mehr.
ERREICHT
Beseitigung der Race Conditions
Durch das DepartureFlag werden Folgeauftrge exklusiv im ConveyorDispo gestartet. Dieser verhindert simultane Startversuche fr die selbe LE und verhindert damit die Race Conditions.
ERREICHT
Verhinderung von Auftragsleichen
Die technische Race Condition (Doppelstart) wurde behoben. Im Testcase Sofortiger Folgeauftrag wurde eine testumgebungsbedingte Auftragsleiche produziert, welche jedoch bei korrektem Abschluss eines vorausgehenden Auftrags nicht zustande kommt.
TEILWEISE ERREICHT
Zentralisierung der Kapazittsprfung
Folgeauftrge durchlaufen, wie alle anderen Initialauftrge auch die Checks innerhalb des ConveyorDispo Prozesses
ERREICHT
Strikte Trennung der Prozesszustndigkeit
HostBooking fungiert rein als Kommunikationsschnittstelle (Bei Spezialfllen, die auerhalb des Projektrahmens liegen sendet HostBooking immer noch Departure Telegramme). ConveyorBooking ist die alleinige ausfhrende Gewalt.
ERREICHT


6.1.3 Soll-Ist-Zeitplanung
Tabelle 4 Soll-Ist-Zeitplanung
Phase
Soll Stunden
Ist Stunden
Abweichung
Begrndung
Vorbereitung/Planung
8
10
+2h
Es gab deutlich mehr Input zum Projekt und der Anlage als erwartet (Einfhrung in die Emulationsumgebung, Schulung zum WCS)
Analyse
15
22
+7h
Einarbeitung und Verstndnis fr die Threads innerhalb der Prozesse ConveyorDispo und HostBooking waren zeitintensiver als angenommen. Das Entwickeln von Ablaufdiagrammen half dem Verstndnis, nahm jedoch ebenfalls Zeit in Anspruch 
Konzeptionierung
15
10
-5h
Das Konzept war fr die Zentralisierung der Startlogik durch die Visualisierung der Threads mittels Ablaufdiagramm schneller vollendet als geplant.
Implementierung
10
6
-4h
Durch das eingefhrte DepartureFlag war das Refactoring berschaubar und deutlich weniger zeitintensiv als in der Planung angenommen.
Testung
12
12
0h
Phase konnte zeitlich nicht vollstndig abgeschlossen werden. Das Beheben des Fehlers und Bestehen von Testcase Sofortiger Folgeauftrag konnte innerhalb des Zeitfensters nicht erfolgen.
Dokumentation
20
20
0h	

Gesamt
80
80
0h


6.2 Fazit & Ausblick
6.2.1 Persnliches und fachliches Fazit
Die Durchfhrung dieses Projekts war fr mich eine fachlich uerst wertvolle Erfahrung. Die grte Herausforderung lag darin, die Funktionen der einzelnen Threads tiefgehend zu durchdringen und ihr komplexes Zusammenspiel innerhalb der realen Anlage einzuordnen. Besonders hilfreich beim Systemverstndnis sowie bei der anschlieenden Konzeptionierung und Implementierung waren die entwickelten Ablaufdiagramme. Mittels dieser Visualisierungen lieen sich die logischen Schwachstellen schnell lokalisieren und ein Lsungsweg erarbeiten. Das Projekt  wurde innerhalb des vorgegebenen Zeitrahmens von 80 Stunden erfolgreich und funktionsfhig abgeschlossen. Die Rollenverteilung zwischen ConveyorDispo und HostBooking ist nun deutlich einheitlicher, stabiler und prozesssicherer aufgebaut.

6.2.2 Ausblick
Die Abnahme des Projekts zeigte, dass das Positionsfeld der DepartureNotification doch ber das LastWhere Feld der LE oder Source Feld von OrdersHost Beziehen lassen. Fr reine Funktionalitt knnte man demnach auf das DepartureLocation Feld verzichten. Um jedoch eine robuste Datenbergabe zwischen DepartureNotification und ConveyorDispo zu gewhrleisten, wird das DepartureLocation Feld beibehalten.
In den Spezialfllen innerhalb des DepartureNotificationHandlers werden noch immer Departure Telegramme von diesem an die SPS versendet. Diese gilt es ebenfalls in den ConveyorDispo Prozess zu verschieben, um die klare Rollentrennung zu vereinheitlichen.
Durch die Verlagerung der Departure Telegramme vom ereignisgesteuerten HostBooking zum zyklisch pollenden ConveyorDispo entsteht ein potenzieller logischer Wettlauf. Wenn HostBooking zu lange braucht, um einen Folgeauftrag mit der DepartureFlag zu markieren, knnte der ConveyorDispo ihm zuvorkommen und den unmarkierten Folgeauftrag ganz normal Verarbeiten. Problem ist, bei einer normalen Verarbeitung wird die Logik fr ein Departure nicht ausgefhrt. Daraus resultiert, dass der Transportauftrag gestartet wird, die physische LE sich jedoch nicht vom Arbeitsplatz wegbewegt. Fr die Behandlung des Szenarios wrde sich ein zustzlicher Status DepartureReady anbieten, welcher fr Folgeauftrge anstelle von Initial gesetzt wird. 







Anhang

Kundendokumentation

Quellcode

Abnahmeprotokoll

Glossar

Prozess & Ablaufdiagramme

Quellenverzeichnis
- Gebhardt WCS Schulung
- Interne StoreWare Wiki
- https://gebhardt-group.com/

TODO // Kundendokumentation, Abnahmeprotokoll, Quellcode, Glossar, Prozess & Ablaufdiagramm, Fazit & Ausblick,  Soll Ist Projektziele, Doku probelesen

Jetzt, 3 testcases, Fazit & Ausblick, Soll-Ist Projektziele




2


